MSC4333: Room state API for moderation bots #4333
Conversation
turt2live
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Moderation bot
There was a problem hiding this comment.
WIP as of writing, but moderation bot exists here: the-draupnir-project/Draupnir#944
Also WIP as of writing, client is here: element-hq/element-web#30648
| bot commands and a new state event published in the moderation bot's management room. | ||
|
|
||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
TODO: Describe why we go with the commands approach instead of something else. The short version is we could support HTTP APIs, toDevice, custom event types (this one is mentioned briefly later), toWidget, etc, but commands are universally easy to support and hook up per MSC4332.
| then sent to the management room (instead of calling the `/ban` API, for example). | ||
|
|
||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
Draupnir in the future is going to require a --no-confirm flag for the ban command. I think if we spot that the org.matrix.msc4332.commandmixin is used in an event that we will have to pretend the --no-confirm flag is present.
| array (instead, treating *all* rooms the client sees as "protected" by that management room). | ||
|
|
||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
So seemingly this MSC tries to create an "adaptor" for bot commands with similar semantics, so that a client can present these as common commands to their users. When in reality the bots have different options and subtly different semantics for each common command.
I think an alternative that should be explored is just defining the common commands and semantics. With careful consideration for what they mean from the client perspective. And letting bots provide dedicated support to these commands and the spec's specific semantics for the commands. Rather than the client trying to adapt to different bot commands with different semantics.
| array (instead, treating *all* rooms the client sees as "protected" by that management room). | ||
|
|
||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Continuing on from https://github.com/matrix-org/matrix-spec-proposals/pull/4333/files#r2454823574 in another line of thought.
Another alternative is to try break down the MSC into other primitives that would allow bot commands to present themselves in the client UI generically. Such as in the user pane from within a room.
A separate line of exploration that could make this a lot easier to do, is if Draupnir interface-manager style prompt support is added to the MSC series. As any command that accepts a user as an argument can then be shown in the user pane. And any other arguments can be prompted for.
There was a problem hiding this comment.
Note: When i say prompt support, i really mean partial commands. Sending a partial command to the bot, so that it can reply dynamically with a selection for the user to make.
There was a problem hiding this comment.
This becomes much easier to design if #4332 is reworked away from a perspective of providing an adaptation layer for "fallback" text based commands1. And instead focus on the command matrix event mixin. As partial commands can then be sent to prompt for individual arguments in any order, regardless of whether they are positional arguments. And this would open the door for the kind of generalisation that would allow commands to be placed in the user pane or other parts of the client UI.
Footnotes
-
Which has already been shown not to work, as commands not specifically adapted to the MSC have lots of differences in syntax and parameter parsing. ↩
Rendered
Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published in my capacity as Tech Lead for T&S, though does not achieve any particular T&S project/goal.